Mobile apps can provide a user in an enterprise with access to their business data by running JavaScript code that use interactive graphical objects (elements), referred to as “widgets.” The SAP Analytics® mobile app product, for example, uses the concept of “stories” that contain widgets to provide data visualization using charts, graphs, tables, and other visual elements to convey a story of the user's enterprise and help discover insights in the data.
WkWebview is a library that is used to load the JavaScript code that handle interactions with such widgets. Before loading a widget, the code needs to set up a story context. The story context contains an instantiation (WkWebview instance) of all the services that are required for the interactions and general story workflow. These services are memory intensive and processor intensive. Because of these constraints, a mobile app can load only a limited number of WkWebview instances. Depending on system architecture (such as in the SAP Analytics® mobile app) and as a practical matter, the mobile app can load only two instances of WkWebview at a time. For the same reasons, due to memory and processing load constraints, each WkWebview instance maintains only one active widget at a time. For basic usage scenarios, on a mobile device such as viewing and interacting with a single chart, this one-widget-at-a-time access may be acceptable.
However, since the story contexts in the different WkWebview instances are completely independent of each other, a consequence of maintaining one widget per WkWebview instance is that it becomes impossible for widgets in different WkWebview instances to communicate with each other when the story context in one widget changes. In the SAP Analytics® mobile app, for example, each widget can contain information that is related to the overall story. Widgets can affect other widgets when a filter is applied on them, and for some filters even the whole story context can be affected thus in turn potentially affecting all the widgets.
In a web application, on a desktop computer, for instance, all the widgets on a given page can be initialized and active at the same time in a story because there will be sufficient memory, processing, and power resources to support several WkWebview instances running several active widgets. When a filter is applied on a widget which affects other widgets on the page, an event is fired to those widgets and any changes can be rendered right away, in real time on the affected widgets.
However, in a mobile device configuration, we cannot initialize all the widgets on a given page at the same time because of the memory constraints CPU power limitation of the mobile device. The mobile device loads only one active widget selected by the user. As soon as the user completes the interaction, the widget is removed from memory so that another widget can be selected and instantiated. In cases when a user applies a filter on a widget that affects another widget, there would be no effect because the affected widget is not present in the memory (not active) and therefore cannot react to the filter. When the user activates the affected widget, changes that should have manifested in that widget due to the filter will not appear.